Skip to content

Skip doc-comment copying and presize token arrays when tokenizing - #23200

Closed
staabm wants to merge 1 commit into
php:masterfrom
staabm:less-comments
Closed

Skip doc-comment copying and presize token arrays when tokenizing#23200
staabm wants to merge 1 commit into
php:masterfrom
staabm:less-comments

Conversation

@staabm

@staabm staabm commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

disclaimer: this change was generated by claude opus. I have little experience with php-src development


The scanner copied every doc comment into CG(doc_comment) even in non-parser mode (token_get_all/PhpToken::tokenize/highlighting), where nothing consumes it and it is immediately discarded; only do it when compiling. Also presize the tokenizer result array (one token per ~5 source bytes) and the dedup hash instead of growing them by doubling.

The scanner copied every doc comment into CG(doc_comment) even in
non-parser mode (token_get_all/PhpToken::tokenize/highlighting), where
nothing consumes it and it is immediately discarded; only do it when
compiling. Also presize the tokenizer result array (one token per ~5
source bytes) and the dedup hash instead of growing them by doubling.
@staabm

staabm commented Aug 10, 2026

Copy link
Copy Markdown
Contributor Author

to be honest, I tried to benchmark this change and was not able to successfully get a meaningful result.
maybe someone with more php-src knowledge is able to produce a meaningful benchmark for this change?

Comment thread ext/tokenizer/tokenizer.c
zend_hash_init(&interned_strings, 128, NULL, NULL, 0);
/* Rough estimate: one token per ~5 source bytes; presizing avoids
* repeated doubling of the result array. */
array_init_size(return_value, ZSTR_LEN(source) / 5 + 8);

@LamentXU123 LamentXU123 Aug 10, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure about this? Now, I see the reason why this improves performance somehow, as claude claims, but this completely depends on the input.

For example, a huge inline HTML, or very long strings only produce a few tokens. but the first insert will allocate packed array capacity based on source bytes. This can turn valid large inputs into avoidable OOM cases that we don't want to see.

As far as I can tell, roughly >160 MiB already exceeds HT_MAX_SIZE on 32 bits.

I didn't run any benchmark tho, so someone need to prove the improvements exists :)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also skeptical about this... the ~5 figure really comes out of thin air.

@Girgias Girgias left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm frankly not interested in reviewing code generated by an LLM.

And if you can't even produce a benchmark showing in what cases this improves then what is even the point?

This might cause regressions elsewhere for all we know.

@staabm staabm closed this Aug 12, 2026
@staabm
staabm deleted the less-comments branch August 12, 2026 13:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants